Time in Database Systems

Data Models and Temporal Databases 5 Booking Meeting Room Time DB Group DC1331 06-Jan-04.10:00 DB Group DC1331 06-Jan-04.10:01 DB Group DC1331 06-Jan-04.10:02 DB Group DC1331 16-Jan-04.11:59 Intro to Databases MC4042 06-Jan-04.10:00 Intro to Databases MC4042 06-Jan-04.11:19 Intro to Databases MC4042 08-Jan-04.10:00 Intro to Databases MC4042 08-Jan-04.11:19 Fig. 19.1 A Fragment of a Timestamp Instance of the Booking relation from Example 19.1. A timestamp temporal database is a first-order structure , where are temporal relations— instances of the temporal extensions . In addition we require that the set be finite for every and . Note that at this point there are no cardinality restrictions imposed on the number of time instants in the instances of abstract temporal relations; we address issues connected with the actual finite representation of these relations in Section 19.6. In the rest of the chapter we use the following example to illustrate various concepts. Example 19.1 Consider a database recording room bookings for meetings in a university. A relational schema booking Meeting Room links meetings to rooms. We assume that rooms are identified by their room numbers and meetings have distinct descriptions (names). Thus our temporal database, assuming the use of the timestamp model, contains a single relational schema with three attributes, Booking Meeting Room Time A tuple in an instance of this relation denotes the fact that a meeting is in a room at time . For simplicity in this chapter we assume that time is measured in minutes. An example instance of this schema is shown in Figure 19.1. To distinguish between non-temporal relations and (the derived) timestamp relations we capitalize the name of the later. The granularity of time in our examples is one minute (more on granularities in Section 19.9). It is important to understand that, e.g., the “DB group” meeting has booked room DC1331 for every time instant between 06-Jan-04.10:00 and 06-Jan-04.11:59. 30th January 2004 16:9 WorldScientific/ws-b9-75x6-50 book-timeai 6 Time in Database Systems This set of tuples, depending on properties of the time domain, can be infinite (e.g., when dense time domain is considered). There are several things to note about the example: an instance of the Booking relation represents complete information about meeting schedule; in particular it contains information about meetings that have already finished (e.g., for accounting and evaluation purposes) as well as about meetings scheduled in the future (e.g., to avoid overbooking of rooms). This is necessary, for example, if we want to schedule another meeting in the future, as we need to make sure no other meeting conflicts with it. For this purpose we need to query the database for empty rooms at the particular future time we desire and such a query is only possible utilizing the closed-world assumption. Second, we assume that distinct meetings have distinct names. Thus the same meeting (e.g., a class) can meet in several different rooms at different times. Moreover the meeting times may not be continuous (as is common, e.g., for classes). If we wish to distinguish between instances of a particular meeting we need to use distinguished names (or an additional attribute). 19.3.1.2 The Snapshot Model The sbstract temporal databases in this model are defined as a mapping of the temporal domain to the class of standard relational databases. This gives a Kripke structure with the temporal domain serving as the accessibility relation. Definition 19.3 (Abstract Snapshot Temporal Database) A snapshot temporal database over , , and is a map , where is the class of finite relational databases over and . It is easy to see that snapshot and timestamp abstract temporal databases are merely different views of the same data and thus can represent the same class of temporal databases. Formally, a snapshot temporal database corresponds to a timestamp temporal database if and only if